This invention generally pertains to interfacing two or more distributed systems that are based on different protocols. A distributed system is a collection of autonomous computing entities, hardware or software, connected by a communication medium. While often the computing entities are geographically dispersed, in some instances they might be separate processors in a multi-processor computer or even separate software routines executing in logically isolated memory space on the same computer. A computing entity need not be a traditional computer, but more generally can be any computing device, ranging from a large mainframe to a refrigerator or a cell phone. A distributed application is an application that executes on a distributed system and one in which parts of the application execute on distinct autonomous computing entities.
Whenever a distinct component of a distributed application requests something (e.g., a data value, a computation) of another component, the former is called a client and the latter is called a service. It is worth noting that the terms service and client are not exclusionary in that an item can be both a client and a service. For example, a routine that calculates the time between two events may be a client of a clock service; if the clock service then calls a routine that converts to Daylight Savings Time, the clock becomes a client and the Daylight Savings Time converter is its service.
Mobile code generally refers to a computer program that can be written on one platform and executed on numerous others, irrespective of differences in hardware, operating system, file system, and many other details of the execution environment. In addition to independence from the physical characteristics of the execution environment, a mobile program may move from one computing entity to another in the middle of its execution.
Mobile code may be pre-compiled, or compiled when it arrives at the execution platform. In the first case, numerous versions of the program must be written and compiled, then matched across run-time environments; this is mobile code in the letter, but not the spirit, of the definition. In addition, the same pre-compiled program cannot move from one platform to a different one during its execution. In the second, the program text may be distributed along with configuration scripts describing what to do in each execution environment. This distributes and delays the specificity of the pre-compiled option. The more interesting, and far more common approach exploits a standard virtual machine, which finesses all the issues of platform heterogeneity. The virtual machine is a program that itself mitigates the machine dependencies and idiosyncrasies, taking the raw program text and compiling it to a binary executable.
FIG. 1 shows a typical distributed application of the existing art based on the Jini/Java. While distributed computing systems of different protocols have different architectures and nomenclature, it will be instructive to describe the Jini architecture to provide an understanding of the functions of modern distributed computing applications. There are two clients 2, 4 and four services 10, 12, 14, 16 that the clients 2, 4 might need. Each service has a service proxy 10a, 12a, 14a, 16a which is a module of mobile code that can be used by clients to invoke that service. A service proxy 10a, 12a, 14a, 16a contains the code needed by a client 2, 4 to interact with a service. For instance if a service is a digital camera on a robotic arm, the interfaces might include Initialize( ), Zoom( ), Rotate( ) and Get_Picture( ). The service proxy 10a, 12a, 14a, 16a may also provide the expected return values for the service, which might include error codes as well.
In addition to clients 2, 4 and services 10, 12, 14, 16 distributed applications need some mechanism for clients to find services. Often such knowledge is assumed a priori, but many distributed applications use a registry, which in Jini is a lookup service. The lookup service 20 is a service with which the other services are registered or advertised to be available for use by clients. In a simple system, where there is no attempt to coordinate replicas of services, each new service registers with the lookup service 20 (in the case of replicas, the onus falls on the client to resolve conflicts and ambiguity). When a service 10, 12, 14, 16 registers, it provides information telling clients 2, 4 how to find it. Commonly, this is a physical location such as an IP address and port number, but in the most modern systems this can be as powerful as giving the lookup service 20 a service proxy 10a, 12a, 14a, 16a, which is mobile code that clients 2, 4 execute and use to invoke the services 10, 12, 14, 16. In this way, the service proxy 10a, 12a, 14a, 16a contains not only location information but instructions for how to use the service 10, 12, 14, 16. While just as necessary for the client 2, 4 as location information, this has generally been assumed as a priori knowledge. When a client 2, 4 wishes to work with a service 10, 12, 14, 16 it locates it through the lookup service 20, downloads the service proxy 10a, 12a, 14a, 16a for that service 10, 12, 14, 16 from the lookup service 20, then uses the service proxy 10a, 12a, 14a, 16a to invoke the service 10, 12, 14, 16. The lookup service 20 may also have attributes of the services 10, 12, 14, 16, such as whether it is a grouped service, what type of group it is, what its cost to use is, how accurate it is, how reliable it is, or how long it takes to execute. In such cases the clients 2, 4 can use the attributes to decide which of a number of services 10, 12, 14, 16 it wishes to use.
Each of the foregoing has access to a communication network 22 so that it is capable of communicating with at least some of the other members in the distributed computing application. The communication network 22 may be wireless, a local area network, an internal computer bus, a wide area network such as the Internet, a corporate intranet or extranet, a virtual private network, any other communication medium or any combination of the foregoing.
In the prior art example shown in FIG. 1, one client 2 is a roadway traffic monitoring program that notifies a user when and where traffic has occurred and the other client 4 is an automated toll collection program. The services are a clock 10, a road sensor 12 that monitors traffic flow on a highway, a toll booth sensor 14 that detects an ID device in each car that passes through the toll, and a credit card charge program 16. When each service 10, 12, 14, 16 becomes available to the application it registers with the lookup service 20 and provides the lookup service with its service proxy 10a, 12a, 14a, 16a. 
When the traffic monitoring client 2 begins, it queries the lookup service to see if a clock is available and what sensors are available. The lookup service 20 responds by providing the client 2 with the clock proxy 10a, the road sensor proxy 12a and the toll booth sensor proxy 14a. The traffic monitoring client 2 uses the service proxies 10a, 12a, 14a to invoke the clock 10 and the sensors 12, 14, and then to monitor traffic at various times of the day.
Similarly when the toll collector client 4 begins, it queries the lookup service 20 to see if a toll booth sensor 14 and a credit card charge service 16 are available. The lookup service 20 responds by providing this client 4 with the toll booth sensor proxy 14a and the credit card charge proxy 16a. The toll collector client 4 uses the service proxies 14a, 16a, to invoke the toll booth sensor 14 and the credit card charge program 16, and then to identify cars that pass through the toll booth and charge their credit cards for the toll.
The foregoing description of a Jini based distributed computing system demonstrates several aspects of modern architectures. First there is some means for objects to discover each other, generically referred to as a registry, and implemented in Jini through the lookup service. For each object that registers, the registry stores a descriptor which contains information about the object. This may be as simple as a name or more complex such as a description of the attributes and classes of the service. The registry also stores the location in the distributed environment. Under Jini the descriptor and location are combined into the service proxy.
In many instances, there are two or more distributed systems based upon different frameworks that operate using different protocols. This may occur due to the existence of legacy systems, because of the merger of two different organizations, or when developing enterprise wide solutions from best-of-breed components. It may also occur when integrating an internal system with a public system.
As used herein a “protocol” is the set of predefined mechanisms that autonomous computing entities within a distributed computing system use to communicate and interact with each other. Each layer of abstraction in the system has a protocol (or suite of protocols) appropriate for it. For example, at the level of the operating system, raw socket communication with IP (the internet protocol) is used, whereas at the application layer and higher, frameworks with more comprehensive end-to-end semantics such as RMI (within J2EE and Jini distributed applications), and IIOP (within CORBA applications) are used. In any one application domain, the expected semantics and syntax of the protocol are natively understood, but to bridge between domains, translations ensuring the proper syntax and semantics are necessary.
A framework is a distributed system that consists of one or more protocols and a registry. A system is the hardware and software that implements the framework using the one or more protocols.
Generally, if two different protocols are being used a gateway of some sort is necessary between the two systems as shown in FIG. 2. This gateway 8 is also sometimes known as “middleware” and is also referred to as “protocol adapter” or “translator”. The function of the gateway 8 is to translate communications between the two systems. In theory a gateway should translate all possible commands and responses available in the two systems. Since this is not practical, system designers generally choose a subset of commands and responses for the known objects in the systems and integrate these into the gateway prior to execution. New objects in either system generally cannot be handled by the gateway without adding new code to the gateway. FIG. 2 demonstrates commands from each system's clients passing through the gateway to services in the other system. Responses from the services may also pass back through the gateway to the clients in the other system (not shown).
While it is known in the prior art to have automated methods of writing portions of gateways, in general gateways are very labor intensive to design and code and very difficult to test. This is due, among other reasons, to the large number of commands and responses possible between two systems as well as the various possible logic state of either system.